home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9608 / 000008_owner-urn-ietf _Tue Aug 13 10:04:46 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA14784 for urn-ietf-out; Tue, 13 Aug 1996 10:04:46 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA14778 for <urn-ietf@services.bunyip.com>; Tue, 13 Aug 1996 10:04:35 -0400
  3. Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA10899  (mail destined for urn-ietf@services.bunyip.com); Tue, 13 Aug 96 10:04:05 -0400
  5. Received: from jon by weeble.lut.ac.uk with local (Exim 0.54 #1)
  6.     id E0uqK37-0005yG-00; Tue, 13 Aug 1996 15:02:25 +0100
  7. Date: Tue, 13 Aug 1996 15:02:24 +0100 (BST)
  8. From: Jon Knight <jon@net.lut.ac.uk>
  9. X-Sender: jon@weeble.lut.ac.uk
  10. To: Lewis Girod <girod@LCS.MIT.EDU>
  11. Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  12. Subject: Re: [URN] nasty rewriting rules
  13. In-Reply-To: <9608130628.AA03241@skadhwe.lcs.mit.edu>
  14. Message-Id: <Pine.SUN.3.91.960813143052.8034o-100000@weeble.lut.ac.uk>
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: Jon Knight <jon@net.lut.ac.uk>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. On Tue, 13 Aug 1996, Lewis Girod wrote:
  23. > (4) Regexp interpreters are hard to implement if they are not already
  24. > available on the target system, whereas the languages in my proposal
  25. > have been implemented quite easily.
  26.  
  27. Regexp interpreters are already available in source code format that you 
  28. can just plug and play on many current platforms and which will ease 
  29. porting to new architectures.
  30.  
  31. > There are two questions here.  First, this statement is only true
  32. > given that the structure of the name scheme actually remains
  33. > consistent with this set stucture in the context of NAPTR (this gets
  34. > back to point (1) above).  If they were resolved with NAPTR using
  35. > regexps little would prevent someone from changing the format of an
  36. > ISBN in various ways; there is no technical impediment to this, and if
  37. > the top level ISBN naming authority doesn't want it to happen their
  38. > only recourse is legal.
  39.  
  40. Surely though as long as the end users are using "legal" ISBNs in their
  41. URNs, the rewriting that happens is just the business of the people
  42. "owning" that ISBN and their resolution agents (might be one and same
  43. thing in some cases).  If the resolution agents at the top level of a
  44. naming authority reject "illegal" constructs in that scheme that they
  45. might get given, people will soon get the idea and stop using them.  If
  46. the top level naming authority never see the "illegal" rewritten versions
  47. then that's fine as it means that the rewriting is happening in private
  48. lower down the resolution tree.  I'd say that "enforcement" is just a
  49. private thing within a particular naming scheme resolution tree and isn't
  50. something we should be dipping our toes into (not if we want URNs in this
  51. lifetime anyway). 
  52.  
  53. > This should make it easier for
  54. > people to learn and program in the ``language'' (if such a simple
  55. > thing can be called a language!!) while at the same time making syntax
  56. > errors less likely.  For example, we could use S-expressions (pardon
  57. > my rough adherence to standard BNF form..):
  58.  
  59. I can feel an Emacs mode coming on... :-) :-)
  60.  
  61. > So for example, given a canonical form email address mail:edu.mit.lcs@girod
  62. > 
  63. >   ((eat-including ":" &replace-with "")
  64. >    (eat-until "@" ©)
  65. >    (eat-including "@" &replace-with ".mail-urn"))
  66. > 
  67. > Would ``compile'' to ``x":"+p"";x"@"-v;x"@"+p".mail-urn";'', and would
  68. > generate the pair ("mail-urn.lcs.mit.edu", "girod").  Note that the
  69. > translation took care of removing the ``urn:'' if it was there.  This
  70. > or something like it should be simple enough to learn.
  71.  
  72. And this is simpler that regexps?  As a sysadmin I'd much rather use 
  73. something I'm already used to (ie: regexps) rather than learning (and 
  74. making mistakes in) another new syntax.  Of course those of us that do 
  75. want regexp are still free to have a "NAPTRclassic" (:-) ) namespace 
  76. hived off using SRV records that does do regexp replacement, so maybe we 
  77. can all have our cake and eat it?
  78.  
  79. Tatty bye,
  80.  
  81. Jim'll
  82.  
  83. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  84. Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
  85. Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
  86. * I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *
  87.  
  88.